home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-iplpdn-multi-isdn-00.txt < prev    next >
Text File  |  1993-03-03  |  18KB  |  558 lines
  1.  
  2. Draft                Multiprotocol ISDN            Feb. 1993
  3.  
  4.  
  5. INTERNET DRAFT
  6. Expires: August 16, 1993
  7.  
  8.  
  9.  
  10.  
  11.       The Transmission of Multi-protocol Datagrams 
  12.                     over Circuit-mode ISDN
  13.  
  14.  
  15. Keith Sklower
  16. Computer Science Department
  17. University of California, Berkeley
  18.  
  19. 1.  Status of This Memo
  20.  
  21. This  document  is  an  Internet Draft.  Internet Drafts are
  22. working documents of the  Internet  Engineering  Task  Force
  23. (IETF),  its Areas, and its Working Groups.  Note that other
  24. groups may also distribute  working  documents  as  Internet
  25. Drafts.
  26.  
  27. Internet  Drafts  are draft documents valid for a maximum of
  28. six months.  Internet Drafts may be  updated,  replaced,  or
  29. obsoleted  by other documents at any time.  It is not appro-
  30. priate to use Internet Drafts as reference  material  or  to
  31. cite  them  other  than  as a ``working draft'' or ``work in
  32. progress.''
  33.  
  34. Please check the 1id-abstracts.txt listing contained in  the
  35. internet-drafts    Shadow    Directories   on   nic.ddn.mil,
  36. nnsc.nsf.net,    nic.nordu.net,     ftp.nisc.sri.com,     or
  37. munnari.oz.au  to  learn  the current status of any Internet
  38. Draft.
  39.  
  40. 2.  Abstract
  41.  
  42. This document describes means for transmitting Internet Pro-
  43. tocols  across public data networks using circuit-mode ISDN.
  44. It describes compatible alternatives, discusses the relative
  45. merits  of  each  and  provides  methods  for discrimination
  46. between them.  The intention is to  capture  in  a  slightly
  47. more  formal  way the level of consensus reached at the 24th
  48. and 25th IETF meetings.
  49.  
  50. 3.  Acknowledgements
  51.  
  52. The author specifically wishes to thank Clifford  Frost  and
  53. William  Jolitz  for  many extensive discussions on the sub-
  54. ject, and more generally  the  IP  over  Large  Public  Data
  55.  
  56.  
  57. Sklower                                     [Page 1]
  58.  
  59.  
  60.  
  61. Draft                Multiprotocol ISDN            Feb. 1993
  62.  
  63.  
  64. Networks  working  group,  whose  deliberations this memo is
  65. supposed to reflect.  Extensive references are made to  ear-
  66. lier work by Leifer et al. [1], and Murakami et al. [2].
  67.  
  68. 4.  Conventions
  69.  
  70. The  following language conventions are used in the items of
  71. specification in this document:
  72.  
  73. o    Must, Shall or Mandatory -- the  item  is  an  absolute
  74.      requirement of the specification.
  75.  
  76. o    Should  or  Recommended -- the item should generally be
  77.      followed for all but exceptional circumstances.
  78.  
  79. o    May or Optional -- the item is truly optional  and  may
  80.      be  followed  or  ignored according to the needs of the
  81.      implementor.
  82.  
  83. 5.  Introduction
  84.  
  85. The advent of Circuit-mode ISDN has provided the possibility
  86. of much higher rates of information exchange than previously
  87. possible over modems and voice-grade lines.   We  anticipate
  88. the  use  of this technology to encourage ``tele-commuting''
  89. (making it more possible for people to work  effectively  at
  90. home),  and  to  reduce  the  cost of data communications in
  91. businesses having  geographically  dispersed  sites.   Other
  92. applications,  such  as  multi-media  conferencing, are much
  93. more economically feasible than before.  The contribution by
  94. Murakami  also  cites  the use of ISDN to acquire additional
  95. bandwidth for  handling  excess  traffic  in  parallel  with
  96. leased  lines, and more generally back-up of a failed leased
  97. line.
  98.  
  99. Given the newness of the technology, the  diversity  of  its
  100. applications,  and its wide availability, it is not surpris-
  101. ing that a number of incompatible link level  protocols  are
  102. coming  into  use  for  the  transmission  of data over ISDN
  103. links.  Examples are the use of SLIP [3] and PPP [4,5]  over
  104. asynchronous  terminal  adapters  using  V.120 [6], PPP over
  105. synchronous terminal adapters using V.120 or  directly  over
  106. the  B channel via native ISDN interfaces, and both the Mul-
  107. tiprotocol Encapsulation  over  X.25  [7],  or  Mutltiprocol
  108. Encapsulation  over  Frame Relay [8] directly on the B chan-
  109. nel.  There are even  other  examples  cited  in  Murakami's
  110. paper.
  111.  
  112. In this paper we recommend a primary choice of encapsulation
  113. - -- that described in RFC 1294.  We also suggest two  accept-
  114. able alternatives for specific situations: PPP and X.25.
  115.  
  116.  
  117.  
  118.  
  119. Sklower                                     [Page 2]
  120.  
  121.  
  122.  
  123. Draft                Multiprotocol ISDN            Feb. 1993
  124.  
  125.  
  126. The contribution by Murakami suggests using out-of-band sig-
  127. naling for negotiating the  link-layer  protocol  and  other
  128. configuration  parameters  using  ISDN  Information Elements
  129. such as UUI and BC.  It is the experience of the members  of
  130. the  IPLPDN  that ISDN implementation are as yet so diverse,
  131. the deployment of Switching System 7 so  limited,  and  sub-
  132. scription  policies  by the regional providers so different,
  133. that user cannot depend on having these information elements
  134. passed  end-to-end.  The likeliest element to be passed end-
  135. to-end is LLC; this memo proposes a method for  chosing  the
  136. link-layer  protocol  based  on this element when available.
  137. Where it is not available,  an  algorithm  is  proposed  for
  138. ``negotiating'' the protocol by in-band exchange of data.
  139.  
  140. Other  configuration  parameters  can  be negotiated in band
  141. using PPP, even for the  Frame  Relay  and  X.25  cases,  as
  142. described in PNMI[9].
  143.  
  144. 6.  Principal Recommendations
  145.  
  146. 6.1.  RFC 1294
  147.  
  148. 6.1.1.  Specific Encoding
  149.  
  150. RFC 1294 specifies the transmission of datagrams in a format
  151. according to Q.922.  As this is an HDLC framing, it is  com-
  152. pletely suitable for use on an ISDN B channel.
  153.  
  154. The RFC does not describe how the Q.922 header is generated;
  155. it was assumed that a genuine frame relay would  provide  it
  156. as a normal consequence of its operation.  All other details
  157. of the encapsulation were completely specified by this  RFC.
  158.  
  159. In  fact,  it is possible to employ ISDN to gain access to a
  160. Frame Relay, and when doing so packets received from it will
  161. contain  a  valid  DLCI.   Obviously, a system communicating
  162. with a frame relay must set the DLCI's appropriately.
  163.  
  164. When transmitting datagrams across an ISDN  B-channel  using
  165. this format between systems which are not Frame Relays, such
  166. systems MUST provide a valid DLCI header.  As such, the low-
  167. est  order  bit  of the first byte transmitted MUST be zero.
  168. The DLCI may be configured by prior agreement to any accept-
  169. able  value.   A default DLCI value of 16 is consistent with
  170. current  ANSI  recommendations  (T1.617),  however  at  some
  171. future  time  when frame relay service is offered over the D
  172. channel, the default DLCI value should be 512 (T1.618).
  173.  
  174. 6.1.2.  Advantages of Frame Relay Encapsulation
  175.  
  176. Proponents for this method have claimed that RFC 1294 encap-
  177. sulation is very simple to implement; in fact it is possible
  178. to prepend  a  fixed  header  to  all  datagrams  sent,  and
  179.  
  180.  
  181. Sklower                                     [Page 3]
  182.  
  183.  
  184.  
  185. Draft                Multiprotocol ISDN            Feb. 1993
  186.  
  187.  
  188. completely  ignore  the  first  few  bytes  of  any datagram
  189. received.
  190.  
  191. When systems have been compatibly preconfigured, no  further
  192. state  must be maintained on a per B-channel basis.  This is
  193. clearly of concern for circumstances like  multiple  primary
  194. rate  interfaces  coming  into  a single router, thus poten-
  195. tially supporting hundreds of B-Channels.
  196.  
  197. Furthermore, it is possible to start  transmitting  data  as
  198. soon  as  the circuit has been established, thereby reducing
  199. latency.  PPP and X.25, by contrast require an  exchange  of
  200. packets to declare the link up.
  201.  
  202. 6.2.  PPP
  203.  
  204. The  proponents for PPP argue that it is widely implemented,
  205. and constructed in such a  way  to  force  interoperability.
  206. The  details  of  the  protocol  are completely specified by
  207. RFC's 1331 and 1332, and are also applicable to  any  situa-
  208. tion  where  synchronous  transmission  of data is possible.
  209. They argue that any commercial router one procures is likely
  210. already  to  have  code  supporting  PPP, and it is flexible
  211. enough to adapt to all the situations cited as  applications
  212. in this memo.
  213.  
  214. 6.3.  RFC 1356/B-Channel X.25
  215.  
  216. Systems  supporting  exchanging information according to OSI
  217. conventions are required to support X.25 over the B-channel,
  218. and RFC 1356 provides means for conveying Internet Protocols
  219. in this situation.
  220.  
  221. 7.  In-Band Link Protocol Negotiation
  222.  
  223. The algorithm is that the caller starts transmitting data or
  224. negotiation  according  to  his preferred encapsulation, and
  225. the callee just figures out what is desired by inspection of
  226. the  first  correctly  framed  HDLC  packet.   If either the
  227. caller or callee insists on doing PPP or  X.25  it  will  be
  228. impossible to shut them up.
  229.  
  230. 7.1.  Caller's Algorithm
  231.  
  232. A  system  wishing  to  exchange  information using RFC-1294
  233. encapsulation MUST transmit some packet with  a  valid  two-
  234. byte  DLCI.   The  calling system MAY transmit protocol data
  235. immediately, given suitable preconfiguration.   The  calling
  236. system  MAY also initiate parameter negotiation according to
  237. PNMI, using the RFC-1294 encapsulation.
  238.  
  239. A system wishing to  exchange  information  using  PPP  will
  240. issue  an  LCP packet in native PPP format, according to the
  241.  
  242.  
  243. Sklower                                     [Page 4]
  244.  
  245.  
  246.  
  247. Draft                Multiprotocol ISDN            Feb. 1993
  248.  
  249.  
  250. requirements of RFC 1331; i.e. the first byte will be  0xff,
  251. and the second byte will be 0x3, etc.
  252.  
  253. A  system  wishing  to  use  X.25  will issue a SABM with an
  254. address of station A,  according  to  the  OSI  implementors
  255. agreement [10].
  256.  
  257. 7.2.  Callee's Algorithm
  258.  
  259. The  called  system  will  wait until it has received a cor-
  260. rectly framed and checksummed HDLC packet  and  inspect  the
  261. very  first  byte.  PPP requires that the station address be
  262. all ones (0xff).  Conventional X.25 HDLC requires a  station
  263. address of either 1 or 3.  The 2,3 or 4 byte DLCI Q.922 for-
  264. mats all require that the low order bit of the first byte to
  265. be  zero.  Thus, it is possible for a called system support-
  266. ing all  three  methods  to  unambiguously  determine  which
  267. encapsulation is desired and respond in the appropriate man-
  268. ner.
  269.  
  270. 8.  Out of Band Signaling
  271.  
  272. {Warning - Meta paragraph.  At the last IETF meeting, it was
  273. agreed  that  somebody  would  approach ANSI for obtaining a
  274. code point for the LLC-IE byte 7 "user information  layer  3
  275. protocol"  that would indicate PPP.  I probably have botched
  276. this section but I'm going to include it to make  it  easier
  277. for whoever edits this next}.
  278.  
  279. 8.1.  Caller's Requirements
  280.  
  281. In  cases where the LLC information element is available and
  282. can be transmitted to be relied on end to end, and the  sys-
  283. tem  wishes to communicate using the RFC-1294 encapsulation,
  284. a system MUST encode the LLC-IE in the following way in  his
  285. setup message:
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305. Sklower                                     [Page 5]
  306.  
  307.  
  308.  
  309. Draft                Multiprotocol ISDN            Feb. 1993
  310.  
  311.  
  312. 8        7     6       5    4    3    2    1
  313. - -----------------------------------------------------------
  314. 0        1     1       1    1    1    0    0
  315. 0               Low Layer Compatibility                     Octet 1
  316. - -----------------------------------------------------------
  317.                .
  318.                .
  319.                .
  320. - -----------------------------------------------------------
  321. 1        1     0       0    1    1    1    1                Octet 6
  322. ext   layer 2 ident    Core Aspects of Q.922 (Frame Relay)
  323.  
  324. - -or-
  325.  
  326. 1        1     0       0    1    1    1    0                Octet 6
  327. ext   layer 2 ident    Full Q.922 (LAPF)
  328. - -----------------------------------------------------------
  329. 1        1     1       0    1    0    1    1                Octet 7
  330. ext   layer 3 ident    ISO/IEC TR 9577 (Protocol Identifi-
  331.          cation in the Network Layer)
  332. - -----------------------------------------------------------
  333.  
  334. In  cases  where  the  system wishes to exchange information
  335. using RFC-1356/X.25 PLP/LAPB a system MUST encode the LLC-IE
  336. in the following way in his setup message:
  337.  
  338.  
  339. 8        7     6       5    4    3    2    1
  340. - -----------------------------------------------------------
  341. 0        1     1       1    1    1    0    0
  342. 0               Low Layer Compatibility                     Octet 1
  343. - -----------------------------------------------------------
  344.                .
  345.                .
  346.                .
  347. - -----------------------------------------------------------
  348. 1        1     1       0    0    1    1    0                Octet 6
  349. ext   layer 2 ident    CCITT Recommendation X.25 link level
  350. - -----------------------------------------------------------
  351. 1        1     1       0    0    1    1    0                Octet 7
  352. ext   layer 3 ident    CCITT Recommendation X.25 packet level
  353. - -----------------------------------------------------------
  354.  
  355. 8.2.  Callee's Algorithm
  356.  
  357. If the LLC-IE exactly matches that generated by the caller's
  358. algorithm, the system SHOULD proceed according to the encap-
  359. sulations  spelled  out  here.   The  callee MAY inspect the
  360. first correctly framed HDLC packet to see  that  it  matches
  361. the encapsulation scheme described.
  362.  
  363. If  the LLC-IE contains other values, the system SHOULD pro-
  364. ceed according to the ``wait-and-see''  algorithm  described
  365.  
  366.  
  367. Sklower                                     [Page 6]
  368.  
  369.  
  370.  
  371. Draft                Multiprotocol ISDN            Feb. 1993
  372.  
  373.  
  374. above.   However,  system  MAY refuse the connection, or the
  375. system MAY make the following inferences: If the User infor-
  376. mation  layer  3  protocol is 0 1 0 0 0 (ISO 8348 Connection
  377. oriented  network  service),  the  system  MAY  assume  that
  378. RFC-1356/X.25  operation is requested.  If the User informa-
  379. tion layer 3 protocol is 0 1 0 0 1  the  system  MAY  assume
  380. that  only  ISO  8473 packets will be routed, (just as if an
  381. X.25 call had been placed with a CUD of 81).
  382.  
  383. A system MAY also assume  that  octet  7  with  a  value  of
  384. 0 1 1 1 0  indicates  a  desire  to encapsulate according to
  385. RFC-1294.
  386.  
  387. 9.  Addressing Stated Requirements of Earlier Work
  388.  
  389. 9.1.  Leifer et al
  390.  
  391. A goal of this proposal was to be able to use  bandwidth  on
  392. demand,  and  obtain the advantage of using multiple B chan-
  393. nels for transmitting traffic between two hosts.
  394.  
  395. There are a number of possible ways of doing this which will
  396. be discussed at length in a separate draft.  For purposes of
  397. illustration, we will summarize the methods discussed at the
  398. November,  1992  IETF:  Almost  all the methods require some
  399. means of identifying which channels are  to  be  aggregated,
  400. which  could  be  done  by the methods discussed in PNMI, or
  401. potentially by use of the calling party information element.
  402.  
  403.  (1)   Use  the  bank-teller's  algorithm: assign a complete
  404.        packet to whatever channel is next free.
  405.  
  406.  (2)   Employ ISO 7776[11] multilink  procedure.   (This  is
  407.        being pursued by the PPP working group).
  408.  
  409.  (3)   Adapt  the  fragmentation  and  reassembly scheme for
  410.        RFC-1294 for bridged packets, regarding the  fragment
  411.        identifier  as  applying  to all packets from a given
  412.        peer rather than from a given PVC.
  413.  
  414.  (4)   Rely on hardware and packet switching facilities that
  415.        combine  multiple B-channels into a single (HDLC) bit
  416.        stream, such as the BONDING proposal currently  being
  417.        discussed by ANSI T1.
  418.  
  419. 9.2.  Murakami et al
  420.  
  421. A  major  concern  of  this paper was the use of out-of-band
  422. signaling to negotiate compatible configuration  parameters.
  423. It is the contention of this author that any parameter need-
  424. ing to be negotiated in this scheme should  be  able  to  be
  425. done so by PNMI, and if it can't then PPP should be extended
  426. to negotiate that parameter.
  427.  
  428.  
  429. Sklower                                     [Page 7]
  430.  
  431.  
  432.  
  433. Draft                Multiprotocol ISDN            Feb. 1993
  434.  
  435.  
  436. 10.  References
  437.  
  438. [1]  Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork
  439.      Control  Protocol  for  ISDN  Circuit-Switching" IPLPDN
  440.      Working Group, Internet Draft (Expired), March 1991.
  441.  
  442. [2]  Muramaki, K., and Sugawara, T., "A Negotiation Protocol
  443.      for  Mutliple  Link-Protocol  over ISDN Circuit Switch-
  444.      ing", IPLPDN Working  Group,  Committee  Document,  May
  445.      1992.
  446.  
  447. [3]  Romkey,  J.L.,  "A  Nonstandard  for Transmission of IP
  448.      Datagrams over Serial Lines:  SLIP."   Network  Working
  449.      Group, RFC-1055, June 1988.
  450.  
  451. [4]  Simpson, W., "The Point-to-Point Protocol (PPP) for the
  452.      Transmission of Multi-protocol Datagrams over Point-to-
  453.      Point  Links",  Network  Working  Group,  RFC-1331, May
  454.      1992.
  455.  
  456. [5]  McGregor, G., "The PPP Internet Protocol Control Proto-
  457.      col  (IPCP)" Network Working Group, RFC-1332, May 1992.
  458.  
  459. [6]  CCITT, "Recommendation V.120: Data Communications  over
  460.      the Telephone Network" Blue Book, ITU 1988
  461.  
  462. [7]  Malis,  A.,  Robinson,  D.,  Ullman  R., "Multiprotocol
  463.      Interconnect on X.25 and ISDN in the Packet Mode", Net-
  464.      work Working Group, RFC-1356, August 1992.
  465.  
  466. [8]  Bradley,  T.,  Brown, C., and Malis, A., "Multiprotocol
  467.      Interconnect over Frame Relay", Network Working  Group,
  468.      RFC-1294, January 1992.
  469.  
  470. [9]  Sklower,  K.  and Frost, C.  "Parameter Negotiation for
  471.      the Multiprotocol Interconnect" IPLPDN  Working  Group,
  472.      Committee Document, November 1992.
  473.  
  474. [10] Boland,  F.,  editor, "Stable Implementation Agreements
  475.      for Open Systems Interconnection Protocols:  Version  2
  476.      Edition  1",  NIST  Workshop  for  Implementors of OSI,
  477.      NIST, February 1989.
  478.  
  479. [11] Internation Organisation for Standardization,  "HDLC  -
  480.      Description  of  the X.25 LAPB-Compatible DTE Data Link
  481.      Procedures", Internation Standard 7776, 1988
  482.  
  483. 11.  Author's Address
  484.  
  485. Keith Sklower
  486. Computer Science Department
  487. 570 Evans Hall
  488. University of California
  489.  
  490.  
  491. Sklower                                     [Page 8]
  492.  
  493.  
  494.  
  495. Draft                Multiprotocol ISDN            Feb. 1993
  496.  
  497.  
  498. Berkeley, CA  94720
  499.  
  500. Phone:  (510) 642-9587
  501. Email:  sklower@cs.Berkeley.EDU
  502.  
  503. 12.  Expiration Date of this Draft
  504.  
  505. August 16, 1993
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553. Sklower                                     [Page 9]
  554.  
  555.  
  556. ------- End of Forwarded Message
  557.  
  558.